맨위로가기

파이프라인 (컴퓨팅)

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

파이프라인(컴퓨팅)은 공장의 조립 라인과 유사하게 여러 단계를 거쳐 데이터를 처리하는 기술이다. 각 단계가 병렬로 작동하여 전체 시스템의 효율성을 높이며, 명령어 파이프라인, 그래픽 파이프라인, 소프트웨어 파이프라인 등 다양한 분야에서 활용된다. 파이프라인은 처리량을 증가시키지만, 지연 시간을 줄이지는 않으며, 설계 시 단계별 균형, 버퍼링, 종속성 처리 등을 고려해야 한다. 하드웨어 및 소프트웨어로 구현되며, 한국에서도 빅데이터 처리 등에서 파이프라인 기술이 활용되고 있다.

더 읽어볼만한 페이지

  • 명령어 처리 - 멀티스레딩
    멀티스레딩은 프로세스 내에서 여러 스레드를 동시 실행하여 처리 능력을 향상시키는 기술로, 응답성 향상과 자원 공유 등의 장점이 있지만, 자원 간섭과 소프트웨어 복잡성 증가 등의 단점도 존재하며, 다양한 모델과 구현 방식, 스레드 스케줄러, 가상 머신 활성화 가능성 등을 고려해야 한다.
  • 명령어 처리 - 마이크로아키텍처
    마이크로아키텍처는 명령어 집합 아키텍처를 구현하는 프로세서의 구성 요소, 상호 연결, 작동 방식을 포괄하는 개념으로, 동일 ISA에서 반도체 기술 발전과 새로운 구조 및 회로를 통해 성능 향상을 가능하게 한다.
파이프라인 (컴퓨팅)
개요
유형병렬 처리 기법
분야컴퓨터 과학, 컴퓨터 아키텍처, 운영 체제
기본 원리
설명작업 분할 및 동시 처리
목표처리량 증가 및 효율성 향상
파이프라인 단계 (예시)
단계 1명령어 인출 (Instruction Fetch)
단계 2명령어 해독 (Instruction Decode)
단계 3실행 (Execute)
단계 4메모리 접근 (Memory Access)
단계 5레지스터 기록 (Write Back)
장점
처리량 증가여러 작업을 동시에 처리하여 전체 처리 시간 단축
자원 활용도 향상각 단계가 다른 자원을 사용하므로 시스템 자원 효율적 활용
설계 용이성복잡한 작업을 여러 단계로 분할하여 설계 및 구현 용이
단점
지연 시간 증가단일 작업 처리 시간은 증가할 수 있음
파이프라인 해저드 (Hazard)데이터 의존성, 제어 의존성 등으로 인한 성능 저하
복잡한 제어 로직파이프라인 제어를 위한 추가적인 하드웨어 및 소프트웨어 필요
활용 분야
중앙 처리 장치 (CPU)명령어 파이프라인을 통해 명령어 처리 속도 향상
그래픽 처리 장치 (GPU)병렬 처리 능력을 극대화하여 고성능 그래픽 처리
디지털 신호 처리 (DSP)실시간 신호 처리 및 데이터 분석
소프트웨어데이터 처리 파이프라인 구축을 통한 효율적인 데이터 처리
관련 기술
슈퍼스칼라 (Superscalar)여러 개의 파이프라인을 동시에 실행하여 명령어 처리 능력 향상
아웃 오브 오더 실행 (Out-of-Order Execution)명령어 실행 순서를 변경하여 파이프라인 효율성 극대화
분기 예측 (Branch Prediction)분기 명령어 결과를 예측하여 파이프라인 정지 방지
기타
주의사항파이프라인 깊이가 깊어질수록 해저드 발생 가능성이 높아지므로 적절한 깊이 설정 중요

2. 개념 및 원리

파이프라인은 공장의 조립 라인과 유사한 개념으로 만들어졌다. 예를 들어 자동차 조립 라인이라면, 자동차를 조립하는 과정을 크게 엔진 설치, 문과 후드 설치, 바퀴 설치 등으로 나눌 수 있다. 이 과정을 하나의 조립라인에서 모두 수행하는 것보다, 첫 번째 라인에서 엔진을 설치하여 두 번째 라인으로 보내고, 두 번째 라인에서 문과 후드를 설치하여 세 번째 라인으로 보내고, 세 번째 라인에서 바퀴를 설치하여 조립을 완료한다면, 각각의 라인이 동시에 동작할 수 있어 차량 생산을 더 효율적으로 할 수 있다.

부품마다 별개의 조립 라인을 이용한다고 해서 개별 차량의 생산 시간이 줄어드는 것은 아니다. 오히려 라인 간 이동에 의해 개별 차량의 생산 시간은 늘어날 수도 있다. 파이프라인 구조에서도 마찬가지로, 데이터 처리를 한 단계에서 전부 처리하는 것에 비해 각 데이터 요소의 처리 시간이 줄어들지는 않는다. 그러나 각 파이프라인이 병렬적으로 동시에 동작함으로써 전체 시스템의 효율성 향상을 꾀할 수 있다.

라인 생산 방식과 같은 파이프라인적인 것은 다양한 곳에 존재한다. 자동차 조립을 예로 들어보면, 엔진을 섀시에 설치, 후드 설치, 바퀴 설치가 있으며, 이 순서로 실시한다고 가정한다. 라인의 각 공정에는 1대의 조립 중인 자동차만 있다. 엔진 설치를 마친 자동차는 다음으로 후드 설치 공정으로 옮겨지고, 엔진 설치용 기계 설비는 다음 자동차에 착수할 수 있다. 첫 번째 자동차는 더 나아가 바퀴 설치 공정으로 진행되고, 두 번째 자동차는 후드 설치 공정으로 진행되며, 세 번째 자동차가 엔진 설치 공정으로 진행된다. 엔진 설치에 20분, 후드 설치에 5분, 바퀴 설치에 10분이 걸린다고 하면, 한 번에 한 대씩 조립하면 3대를 조립하는 데 105분이 걸린다. 그러나 라인 생산 방식에서는 75분 만에 3대의 조립이 완료된다. 그 후에도 20분 간격으로 자동차가 조립되어 간다.

만약 한 대의 자동차를 조립하는 데 각각 20분, 10분, 15분이 걸리는 세 가지 작업이 필요하다고 가정해 보면, 세 가지 작업을 모두 하나의 작업대에서 수행한다면 공장은 45분마다 한 대의 차를 생산할 것이다. 세 개의 작업대로 파이프라인을 사용하면 공장은 첫 번째 차를 45분 만에 생산하고, 그 다음부터는 20분마다 한 대씩 생산할 것이다.

이 예시에서 볼 수 있듯이 파이프라인은 지연 시간, 즉 하나의 품목이 전체 시스템을 통과하는 데 걸리는 총 시간을 줄이지 않는다. 하지만 첫 번째 품목 처리 후 새로운 품목이 처리되는 속도인 시스템의 처리량을 증가시킨다.

2. 1. 조립 라인과의 유사성

파이프라인은 공장의 조립 라인과 유사한 개념으로 만들어졌다. 예를 들어 자동차 조립 라인이라면, 자동차를 조립하는 과정을 크게 엔진 설치, 문과 후드 설치, 바퀴 설치 등으로 나눌 수 있다. 이 과정을 하나의 조립라인에서 모두 수행하는 것보다, 첫 번째 라인에서 엔진을 설치하여 두 번째 라인으로 보내고, 두 번째 라인에서 문과 후드를 설치하여 세 번째 라인으로 보내고, 세 번째 라인에서 바퀴를 설치하여 조립을 완료한다면, 각각의 라인이 동시에 동작할 수 있어 차량 생산을 더 효율적으로 할 수 있다.

부품마다 별개의 조립 라인을 이용한다고 해서 개별 차량의 생산 시간이 줄어드는 것은 아니다. 오히려 라인 간 이동에 의해 개별 차량의 생산 시간은 늘어날 수도 있다. 파이프라인 구조에서도 마찬가지로, 데이터 처리를 한 단계에서 전부 처리하는 것에 비해 각 데이터 요소의 처리 시간이 줄어들지는 않는다. 그러나 각 파이프라인이 병렬적으로 동시에 동작함으로써 전체 시스템의 효율성 향상을 꾀할 수 있다.

라인 생산 방식과 같은 파이프라인적인 것은 다양한 곳에 존재한다. 자동차 조립을 예로 들어보면, 엔진을 섀시에 설치, 후드 설치, 바퀴 설치가 있으며, 이 순서로 실시한다고 가정한다. 라인의 각 공정에는 1대의 조립 중인 자동차만 있다. 엔진 설치를 마친 자동차는 다음으로 후드 설치 공정으로 옮겨지고, 엔진 설치용 기계 설비는 다음 자동차에 착수할 수 있다. 첫 번째 자동차는 더 나아가 바퀴 설치 공정으로 진행되고, 두 번째 자동차는 후드 설치 공정으로 진행되며, 세 번째 자동차가 엔진 설치 공정으로 진행된다. 엔진 설치에 20분, 후드 설치에 5분, 바퀴 설치에 10분이 걸린다고 하면, 한 번에 한 대씩 조립하면 3대를 조립하는 데 105분이 걸린다. 그러나 라인 생산 방식에서는 75분 만에 3대의 조립이 완료된다. 그 후에도 20분 간격으로 자동차가 조립되어 간다.

2. 2. 파이프라인의 장점

파이프라인은 공장의 조립 라인과 유사한 개념으로 만들어졌다. 자동차 조립 라인에서 여러 라인이 동시에 동작하여 차량 생산을 효율적으로 하는 것처럼, 파이프라인 구조에서도 각 단계가 병렬적으로 동시에 동작하여 전체 시스템의 효율성 향상을 꾀할 수 있다.

프로세서가 명령을 실행하기 위해 명령 해석, 연산, 메모리 액세스 등을 수행할 때, 각 처리를 담당하는 회로 유닛이 존재한다. 순차 실행 방식에서는 하나의 명령이 모든 단계를 완료한 후에 다음 명령을 실행하여, 현재 진행 중인 단계 외의 유닛은 작동하지 않는다.

시간12345678910
명령1IFIDEXMAWB
명령2IFIDEXMAWB



이러한 유닛들을 효과적으로 활용하기 위해, 유닛 사이에 플립플롭을 삽입하여 분할하고, 클럭마다 각 유닛이 독립적으로 동작할 수 있도록 한 후 차례로 명령을 투입하여 병렬 실행하는 방식을 파이프라인 처리라고 한다. 이를 통해 각 유닛의 하드웨어 자원을 효과적으로 활용하고, 처리 속도를 향상시킨다.

시간12345678910
명령1IFIDEXMAWB
명령2IFIDEXMAWB
명령3IFIDEXMAWB
명령4IFIDEXMAWB
명령5IFIDEXMAWB
명령6IFIDEXMAWB



5단계 파이프라인의 기본적인 작동 방식은 다음과 같다.

# 첫 번째 스테이지에서 명령을 읽어온다(페치).

# 읽기를 마치면(1 클럭 경과) 해당 스테이지는 명령을 다음 스테이지로 옮기고, 다음 명령을 페치한다. 그동안 두 번째 스테이지에서는 읽어온 명령의 디코딩이 시작된다.

# 그것이 끝나면(추가로 1 클럭 경과) 모든 명령을 다음 스테이지로 옮기고, 첫 번째 스테이지는 다음 명령을 페치, 두 번째 스테이지에서는 디코딩을 수행한다. 그리고 세 번째 스테이지에서는 첫 번째 명령의 연산을 수행한다.

# 모든 명령을 다음 스테이지로 옮긴다. 3의 과정에 더하여 네 번째 스테이지에서 메모리 액세스가 수행된다.

# 마찬가지로 다섯 번째 스테이지에서 첫 번째 명령의 결과 저장이 수행된다.

이후 과정은 1~5의 반복이다.

최신 CPU에서는 15단계를 넘는 다단계 파이프라인을 갖는 경우도 있다(슈퍼파이프라인). 스테이지 수는 많을수록 병렬 처리할 수 있는 명령이 증가하지만, 처리 결과가 반영되기까지 시간이 오래 걸리고, 파이프라인 해저드 발생 시 초기화에 시간이 오래 걸린다는 단점이 있다. 반면, 스테이지 수가 적은 파이프라인에서는 처리 결과가 반영되기까지 시간이 짧고, 파이프라인 해저드가 발생해도 초기화가 빠르다.

3. 컴퓨팅 분야에서의 파이프라인

컴퓨팅에서 파이프라인 또는 데이터 파이프라인[1]은 일련의 데이터 처리 요소가 직렬로 연결된 것으로, 한 요소의 출력이 다음 요소의 입력이 된다. 파이프라인의 요소는 종종 병렬 또는 시분할 방식으로 실행된다. 요소 사이에 어느 정도의 버퍼 저장소가 삽입되는 경우가 많다.

컴퓨터 관련 파이프라인에는 다음이 포함된다.


  • 명령어 파이프라인은 클래식 RISC 파이프라인과 같이 여러 명령어를 동일한 회로로 중첩 실행할 수 있도록 중앙 처리 장치(CPU) 및 기타 마이크로프로세서에서 사용된다. 회로는 일반적으로 여러 단계로 나뉘며 각 단계는 한 번에 하나의 명령어의 특정 부분을 처리하여 부분 결과를 다음 단계로 전달한다. 단계의 예로는 명령어 디코딩, 산술/논리, 레지스터 페치가 있다. 이는 슈퍼스칼라 실행, 피연산자 전달, 추측 실행 및 비순차적 실행 기술과 관련이 있다.
  • 대부분의 그래픽 처리 장치(GPU)에서 발견되는 그래픽 파이프라인은 일반적인 렌더링 작업(원근 투영, 창 클리핑, 색상조명 계산, 렌더링 등)의 다양한 단계를 구현하는 여러 산술 논리 장치 또는 전체 중앙 처리 장치로 구성된다.
  • 소프트웨어 파이프라인은 개념적으로 병렬로 실행되는 일련의 컴퓨팅 프로세스 (명령, 프로그램 실행, 작업, 스레드, 프로시저 등)로 구성되며, 한 프로세스의 출력 스트림이 다음 프로세스의 입력 스트림으로 자동 공급된다. 유닉스 시스템 호출 파이프는 이 개념의 전형적인 예이다.
  • HTTP 파이프라인은 새로운 요청을 발행하기 전에 이전 요청이 완료될 때까지 기다리지 않고 동일한 TCP 연결을 통해 여러 HTTP 요청을 발행하는 기술이다.

3. 1. 명령어 파이프라인

CPU의 내부 처리를 설명하기 위해, 다음 약어를 사용한다.

  • IF (Instruction Fetch): 명령어를 명령 캐시에서 읽어온다.
  • ID (Instruction Decode/register read): 제어 신호를 생성하고, 레지스터 파일을 레지스터 지정자로 참조한다.
  • EX (EXecution/address calculation): 수치 계산이나 로드/스토어의 데이터, 주소, 분기 대상을 계산한다.
  • MA (Memory Access): 로드(메모리 읽기)・스토어(메모리 쓰기)를 실행한다.
  • WB (Write Back): 레지스터에 데이터를 기록한다.


파이프라인 처리를 수행하는 경우에도, 여러 명령 간의 의존 관계 때문에 명령의 투입을 중단해야 하는 상황이 발생할 수 있는데, 이를 파이프라인 위험(Pipeline Hazard)이라고 한다. 위험이 발생하면 처리 속도 저하로 이어진다.

3. 1. 1. 파이프라인 해저드

파이프라인 처리를 수행하는 경우에도, 여러 명령 간의 의존 관계 때문에 명령의 투입을 중단해야 하는 상황이 발생할 수 있는데, 이를 파이프라인 위험(Pipeline Hazard)이라고 한다. 위험이 발생하면 처리 속도 저하로 이어진다.

3. 2. 그래픽 파이프라인

3. 3. 소프트웨어 파이프라인

소프트웨어에는 파이프라인적인 처리 패턴이 있다. 스레드를 사용하는 패턴에서 볼 수 있다.

일반적으로 객체 지향의 경우, 정보가 발생하는 측에서 정보를 받는 측으로 정보를 전달할 때는 옵저버 패턴을 사용한다. 파이프라인 처리를 객체 지향으로 구현하는 경우도, 일반적인 메서드 호출이 아닌, 옵저버 패턴으로 앞선 스레드에서 데이터를 받아, 받은 쪽의 스레드에서 큐에 데이터를 쌓는 것이 기본 형태의 구현 방법이다.

앞선 스레드와 뒤의 스레드에서 스레드 경합을 피하기 위해, 큐에 락을 걸고 큐의 읽고 쓰기를 하는 대신, 락 프리 큐를 사용하여, 락을 걸지 않고 큐의 읽고 쓰기를 하는 경우도 많다.

4. 설계 고려 사항

파이프라인 설계에서는 각 스테이지의 균형을 맞추는 것이 중요하다. 상술한 조립 라인의 예로 말하자면, 엔진 공정도, 바퀴 공정도 15분 만에 끝낼 수 있다면, 처리량은 더욱 향상될 것이다. 지연 시간은 그래도 35분이지만, 15분에 1대 간격으로 자동차를 생산할 수 있게 된다.

다른 설계상의 고려 사항으로, 스테이지 간의 적절한 버퍼 마련이 있다. 스테이지의 처리 시간이 불확정적인 경우나, 파이프라인의 도중에 데이터가 생성되거나 파괴되는 경우에는 버퍼가 특히 중요하다.

== 단계별 균형 ==

파이프라인의 처리량은 가장 느린 단계에 의해 결정되므로, 설계자는 각 단계에서 작업 완료에 걸리는 시간이 동일하도록 작업과 자원을 분배해야 한다. 자동차 조립 예시에서 세 단계의 작업이 각각 20분, 10분, 15분이 아니라 모두 15분씩 걸린다면, 대기 시간은 여전히 45분이겠지만 새로운 자동차는 20분이 아닌 15분마다 완성될 것이다.

== 버퍼링 ==

이상적인 상황에서 모든 처리 요소가 동기화되고 처리에 동일한 시간이 소요된다면, 각 항목은 이전 요소가 릴리스하는 즉시 단일 클럭 사이클 내에 각 요소에 의해 수신될 수 있다. 이런 방식으로 항목은 물길의 파도처럼 일정한 속도로 파이프라인을 통과한다. 이러한 "파이프라인 파이프라인"[2]에서는 데이터 항목에 필요한 저장 공간 외에는 단계 간의 동기화나 버퍼링이 필요하지 않다.

보다 일반적으로, 처리 시간이 불규칙하거나 파이프라인을 따라 항목이 생성되거나 파괴될 수 있는 경우 파이프라인 단계 간의 버퍼링이 필요하다. 예를 들어, 화면에 렌더링될 삼각형을 처리하는 그래픽스 파이프라인에서 각 삼각형의 가시성을 확인하는 요소는 삼각형이 보이지 않으면 해당 삼각형을 삭제하거나 부분적으로 숨겨진 경우 두 개 이상의 삼각형 조각을 출력할 수 있다. 애플리케이션이 첫 번째 단계에 항목을 공급하고 마지막 단계의 출력을 소비하는 속도의 불규칙성을 수용하기 위해서도 버퍼링이 필요하다.

두 단계 사이의 버퍼는 두 단계 사이에 적절한 동기화 및 신호 로직을 갖춘 간단한 하드웨어 레지스터일 수 있다. 단계 A가 레지스터에 데이터 항목을 저장하면 다음 단계 B에 "데이터 사용 가능" 신호를 보낸다. B가 해당 데이터를 사용하면 A에 "데이터 수신됨" 신호로 응답한다. 단계 A는 다음 데이터 항목을 레지스터에 저장하기 전에 이 신호를 기다리면서 정지한다. 단계 B는 다음 항목을 처리할 준비가 되었지만 단계 A에서 아직 제공하지 않은 경우 "데이터 사용 가능" 신호를 기다리면서 정지한다.

요소의 처리 시간이 가변적인 경우 전체 파이프라인은 해당 요소와 이전 요소가 입력 버퍼의 항목을 소비할 때까지 기다리면서 종종 정지해야 할 수 있다. 이러한 파이프라인 정지의 빈도는 해당 단계의 입력 버퍼에 하나 이상의 항목을 위한 공간을 제공하여 줄일 수 있다. 이러한 다중 항목 버퍼는 일반적으로 선입선출 대기열로 구현된다. 업스트림 단계는 대기열이 가득 차면 여전히 정지해야 할 수 있지만, 더 많은 버퍼 슬롯이 제공됨에 따라 해당 이벤트의 빈도는 감소한다. 대기열 이론은 처리 시간의 가변성과 원하는 성능에 따라 필요한 버퍼 슬롯 수를 알 수 있다.

== 비선형 파이프라인 ==

어떤 단계가 다른 단계보다 훨씬 오래 걸리거나 오래 걸릴 수 있으며 속도를 높일 수 없는 경우, 설계자는 해당 작업을 병렬로 수행하기 위해 두 개 이상의 처리 요소를 제공할 수 있으며, 단일 입력 버퍼와 단일 출력 버퍼가 있다. 각 요소가 현재 데이터 항목의 처리를 마치면 공통 출력 버퍼로 전달하고 공통 입력 버퍼에서 다음 데이터 항목을 가져온다. 이러한 "비선형" 또는 "동적" 파이프라인의 개념은 단일 대기열에서 고객에게 서비스를 제공하는 두 명 이상의 출납원이 있는 상점이나 은행의 예에서 잘 나타난다.

== 종속성 처리 ==

어떤 응용 프로그램에서, 단계 A에 의한 항목 Y의 처리는 파이프라인의 일부 이후 단계 B에 의한 이전 항목 X의 처리 결과 또는 영향에 의존할 수 있다. 이 경우, 단계 A는 항목 X가 단계 B를 통과하기 전까지는 항목 Y를 올바르게 처리할 수 없다.

이러한 상황은 명령어 파이프라인에서 매우 자주 발생한다. 예를 들어, Y가 이전 명령어 X에 의해 수정되었어야 하는 레지스터의 내용을 읽는 산술 명령어라고 가정해 보자. A를 명령어 피연산자를 가져오는 단계로, B를 결과를 지정된 레지스터에 쓰는 단계로 하자. 만약 단계 A가 명령어 X가 단계 B에 도달하기 전에 명령어 Y를 처리하려고 시도하면, 레지스터는 여전히 이전 값을 포함할 수 있으며, Y의 효과는 부정확할 것이다.

이러한 충돌을 올바르게 처리하기 위해, 파이프라인은 이를 감지하고 적절한 조치를 취하는 추가 회로 또는 논리를 제공받아야 한다. 이를 위한 전략은 다음과 같다.


  • '''스톨링(Stalling):''' A와 같이 영향을 받는 모든 단계는 종속성이 해결될 때까지, 즉 필요한 정보를 사용할 수 있거나 필요한 상태가 달성될 때까지 중단된다.
  • '''항목 재정렬:''' 스톨링 대신, 단계 A는 항목 Y를 옆으로 치워두고 입력 스트림에서 이전 항목과의 종속성이 없는 이후 항목 Z를 찾을 수 있다. 명령어 파이프라인에서 이 기술은 비순차적 실행이라고 한다.
  • '''추측 및 백트래킹:''' 항목 간 종속성의 중요한 예는 명령어 파이프라인에 의한 조건 분기 명령어 X의 처리이다. 실행될 다음 명령어 Y를 가져오는 파이프라인의 첫 번째 단계 A는 X가 피연산자를 가져와 분기를 취할지 여부를 결정할 때까지 작업을 수행할 수 없다. X의 피연산자는 차례로 메인 메모리에서 데이터를 가져오는 이전 명령어에 의존할 수 있으므로 많은 클럭 사이클이 걸릴 수 있다.

: X가 완료될 때까지 기다리는 동안 중단하는 대신, 단계 A는 분기가 취해질지 여부를 추측하고, 해당 추측에 따라 다음 명령어 Y를 가져올 수 있다. 만약 추측이 나중에 부정확한 것으로 밝혀지면 (바라건대 드물게), 시스템은 백트래킹하여 올바른 선택으로 재개해야 한다. 즉, 해당 추측을 기반으로 단계 A 및 이후 단계에서 기계의 상태에 가해진 모든 변경 사항을 취소해야 하고, 파이프라인에 이미 있는 X 다음에 오는 명령어는 플러시해야 하며, 단계 A는 올바른 명령어 포인터로 다시 시작해야 한다. 이 분기 예측 전략은 추측 실행의 특수한 경우이다.

파이프라인 처리를 수행하는 경우에도, 여러 명령 간의 의존 관계 때문에 명령의 투입을 중단해야 하는 상황이 발생할 수 있는데, 이를 파이프라인 위험(Pipeline Hazard)이라고 한다. 위험이 발생하면 처리 속도 저하로 이어진다.

4. 1. 단계별 균형

파이프라인의 처리량은 가장 느린 단계에 의해 결정되므로, 설계자는 각 단계에서 작업 완료에 걸리는 시간이 동일하도록 작업과 자원을 분배해야 한다. 자동차 조립 예시에서 세 단계의 작업이 각각 20분, 10분, 15분이 아니라 모두 15분씩 걸린다면, 대기 시간은 여전히 45분이겠지만 새로운 자동차는 20분이 아닌 15분마다 완성될 것이다.

4. 2. 버퍼링

이상적인 상황에서 모든 처리 요소가 동기화되고 처리에 동일한 시간이 소요된다면, 각 항목은 이전 요소가 릴리스하는 즉시 단일 클럭 사이클 내에 각 요소에 의해 수신될 수 있다. 이런 방식으로 항목은 물길의 파도처럼 일정한 속도로 파이프라인을 통과한다. 이러한 "파이프라인 파이프라인"[2]에서는 데이터 항목에 필요한 저장 공간 외에는 단계 간의 동기화나 버퍼링이 필요하지 않다.

보다 일반적으로, 처리 시간이 불규칙하거나 파이프라인을 따라 항목이 생성되거나 파괴될 수 있는 경우 파이프라인 단계 간의 버퍼링이 필요하다. 예를 들어, 화면에 렌더링될 삼각형을 처리하는 그래픽스 파이프라인에서 각 삼각형의 가시성을 확인하는 요소는 삼각형이 보이지 않으면 해당 삼각형을 삭제하거나 부분적으로 숨겨진 경우 두 개 이상의 삼각형 조각을 출력할 수 있다. 애플리케이션이 첫 번째 단계에 항목을 공급하고 마지막 단계의 출력을 소비하는 속도의 불규칙성을 수용하기 위해서도 버퍼링이 필요하다.

두 단계 사이의 버퍼는 두 단계 사이에 적절한 동기화 및 신호 로직을 갖춘 간단한 하드웨어 레지스터일 수 있다. 단계 A가 레지스터에 데이터 항목을 저장하면 다음 단계 B에 "데이터 사용 가능" 신호를 보낸다. B가 해당 데이터를 사용하면 A에 "데이터 수신됨" 신호로 응답한다. 단계 A는 다음 데이터 항목을 레지스터에 저장하기 전에 이 신호를 기다리면서 정지한다. 단계 B는 다음 항목을 처리할 준비가 되었지만 단계 A에서 아직 제공하지 않은 경우 "데이터 사용 가능" 신호를 기다리면서 정지한다.

요소의 처리 시간이 가변적인 경우 전체 파이프라인은 해당 요소와 이전 요소가 입력 버퍼의 항목을 소비할 때까지 기다리면서 종종 정지해야 할 수 있다. 이러한 파이프라인 정지의 빈도는 해당 단계의 입력 버퍼에 하나 이상의 항목을 위한 공간을 제공하여 줄일 수 있다. 이러한 다중 항목 버퍼는 일반적으로 선입선출 대기열로 구현된다. 업스트림 단계는 대기열이 가득 차면 여전히 정지해야 할 수 있지만, 더 많은 버퍼 슬롯이 제공됨에 따라 해당 이벤트의 빈도는 감소한다. 대기열 이론은 처리 시간의 가변성과 원하는 성능에 따라 필요한 버퍼 슬롯 수를 알 수 있다.

4. 3. 비선형 파이프라인

어떤 단계가 다른 단계보다 훨씬 오래 걸리거나 오래 걸릴 수 있으며 속도를 높일 수 없는 경우, 설계자는 해당 작업을 병렬로 수행하기 위해 두 개 이상의 처리 요소를 제공할 수 있으며, 단일 입력 버퍼와 단일 출력 버퍼가 있다. 각 요소가 현재 데이터 항목의 처리를 마치면 공통 출력 버퍼로 전달하고 공통 입력 버퍼에서 다음 데이터 항목을 가져온다. 이러한 "비선형" 또는 "동적" 파이프라인의 개념은 단일 대기열에서 고객에게 서비스를 제공하는 두 명 이상의 출납원이 있는 상점이나 은행의 예에서 잘 나타난다.

4. 4. 종속성 처리

어떤 응용 프로그램에서, 단계 A에 의한 항목 Y의 처리는 파이프라인의 일부 이후 단계 B에 의한 이전 항목 X의 처리 결과 또는 영향에 의존할 수 있다. 이 경우, 단계 A는 항목 X가 단계 B를 통과하기 전까지는 항목 Y를 올바르게 처리할 수 없다.

이러한 상황은 명령어 파이프라인에서 매우 자주 발생한다. 예를 들어, Y가 이전 명령어 X에 의해 수정되었어야 하는 레지스터의 내용을 읽는 산술 명령어라고 가정해 보자. A를 명령어 피연산자를 가져오는 단계로, B를 결과를 지정된 레지스터에 쓰는 단계로 하자. 만약 단계 A가 명령어 X가 단계 B에 도달하기 전에 명령어 Y를 처리하려고 시도하면, 레지스터는 여전히 이전 값을 포함할 수 있으며, Y의 효과는 부정확할 것이다.

이러한 충돌을 올바르게 처리하기 위해, 파이프라인은 이를 감지하고 적절한 조치를 취하는 추가 회로 또는 논리를 제공받아야 한다. 이를 위한 전략은 다음과 같다.

  • '''스톨링(Stalling):''' A와 같이 영향을 받는 모든 단계는 종속성이 해결될 때까지, 즉 필요한 정보를 사용할 수 있거나 필요한 상태가 달성될 때까지 중단된다.
  • '''항목 재정렬:''' 스톨링 대신, 단계 A는 항목 Y를 옆으로 치워두고 입력 스트림에서 이전 항목과의 종속성이 없는 이후 항목 Z를 찾을 수 있다. 명령어 파이프라인에서 이 기술은 비순차적 실행이라고 한다.
  • '''추측 및 백트래킹:''' 항목 간 종속성의 중요한 예는 명령어 파이프라인에 의한 조건 분기 명령어 X의 처리이다. 실행될 다음 명령어 Y를 가져오는 파이프라인의 첫 번째 단계 A는 X가 피연산자를 가져와 분기를 취할지 여부를 결정할 때까지 작업을 수행할 수 없다. X의 피연산자는 차례로 메인 메모리에서 데이터를 가져오는 이전 명령어에 의존할 수 있으므로 많은 클럭 사이클이 걸릴 수 있다.

: X가 완료될 때까지 기다리는 동안 중단하는 대신, 단계 A는 분기가 취해질지 여부를 추측하고, 해당 추측에 따라 다음 명령어 Y를 가져올 수 있다. 만약 추측이 나중에 부정확한 것으로 밝혀지면 (바라건대 드물게), 시스템은 백트래킹하여 올바른 선택으로 재개해야 한다. 즉, 해당 추측을 기반으로 단계 A 및 이후 단계에서 기계의 상태에 가해진 모든 변경 사항을 취소해야 하고, 파이프라인에 이미 있는 X 다음에 오는 명령어는 플러시해야 하며, 단계 A는 올바른 명령어 포인터로 다시 시작해야 한다. 이 분기 예측 전략은 추측 실행의 특수한 경우이다.

파이프라인 처리를 수행하는 경우에도, 여러 명령 간의 의존 관계 때문에 명령의 투입을 중단해야 하는 상황이 발생할 수 있는데, 이를 파이프라인 위험(Pipeline Hazard)이라고 한다. 위험이 발생하면 처리 속도 저하로 이어진다.

5. 구현

5. 1. 하드웨어 구현

일반적인 마이크로프로세서는 클럭 동기 설계이며, 버퍼가 있는 동기 파이프라인을 사용한다. 이 경우의 스테이지 간 버퍼를 "파이프라인 레지스터"라고 부르며, 전체가 클럭에 의해 동기화된다. 클럭 사이클은 파이프라인의 각 스테이지에서 가장 긴 시간이 걸리는 부분보다 길게 설정한다. 이렇게 함으로써, 이전 스테이지의 결과가 파이프라인 레지스터에 기록된 후, 다음 스테이지가 이를 이용하여 처리할 수 있다.

비동기 파이프라인은 비동기 회로에서 사용된다. 이 경우 파이프라인 레지스터는 비동기적으로 구동된다. 일반적으로 스테이지 간에 요청 메시지와 응답 메시지를 주고받으며 처리를 진행한다. 예를 들어, 어떤 스테이지에서 처리가 완료되었을 때, 다음 스테이지로부터 요청 메시지가 왔다면 응답 메시지를 반환하고, 이전 스테이지에는 요청 메시지를 보낸다. 어떤 스테이지가 응답 메시지를 수신하면, 입력 레지스터에서 읽어들일 수 있으며, 처리를 시작할 수 있다. 버퍼가 있는 비동기 파이프라인을 사용한 마이크로프로세서의 예로 AMULET이 있다.

무버퍼 파이프라인을 "웨이브 파이프라인(wave pipeline)"이라고 부른다. 그 대신, 파이프라인의 각 스테이지의 레이턴시가 균형을 이루도록 설계되어 있다. 따라서 데이터는 파이프라인 상을 파도처럼 흐르며, 각각의 파도는 가능한 짧게 유지된다. 최대 처리 속도는 데이터를 투입할 수 있는 간격에 따라 결정된다. 그보다 짧은 간격으로 데이터를 투입하면, 파도가 서로 간섭하여 결과가 부정확해진다.

5. 2. 소프트웨어 구현

효과적인 구현을 위해, 데이터 파이프라인은 사용 가능한 CPU 코어에 작업을 분산하기 위한 CPU 스케줄링 전략과 파이프라인 단계가 작동할 자료 구조의 사용이 필요하다.[3] 예를 들어, 유닉스 파생 시스템은 운영 체제가 구현한 파이프를 사용하여 다양한 프로세스의 표준 IO를 연결하는 명령을 파이프라인화할 수 있다. 일부 운영 체제는 파이프라인에서 여러 프로그램 실행을 연결하는 유닉스 계열 구문을 제공할 수 있지만, 진정한 파이프라인이 아닌 간단한 직렬 실행으로 구현할 수 있다. 즉, 다음 프로그램을 시작하기 전에 각 프로그램이 완료될 때까지 기다린다.

더 낮은 수준의 접근 방식은 단계별 작업을 예약하기 위해 운영 체제에서 제공하는 스레드에 의존할 수 있다. 스레드 풀 기반 구현과 단계별 스레드 구현 모두 가능하며 존재한다.[3]

협력적 멀티태스킹에 의존하는 다른 전략도 존재하는데, 이는 여러 실행 스레드와 추가 CPU 코어가 필요하지 않다. 예를 들어, 코루틴 기반 프레임워크를 사용하여 라운드 로빈 스케줄러를 사용하는 것이다. 이 맥락에서 각 단계는 자체 코루틴으로 인스턴스화되어 라운드 작업을 완료한 후 스케줄러로 제어를 다시 넘길 수 있다. 이 접근 방식은 프로세스 단계가 타임 슬라이스를 남용하지 않도록 신중하게 제어해야 할 수 있다.

소프트웨어에는 파이프라인적인 처리 패턴이 있다. 스레드를 사용하는 패턴에서 볼 수 있다.

일반적으로 객체 지향의 경우, 정보가 발생하는 측에서 정보를 받는 측으로 정보를 전달할 때는 옵저버 패턴을 사용한다. 파이프라인 처리를 객체 지향으로 구현하는 경우도, 일반적인 메서드 호출이 아닌, 옵저버 패턴으로 앞선 스레드에서 데이터를 받아, 받은 쪽의 스레드에서 큐에 데이터를 쌓는 것이 기본 형태의 구현 방법이다.

앞선 스레드와 뒤의 스레드에서 스레드 경합을 피하기 위해, 큐에 락을 걸고 큐의 읽고 쓰기를 하는 대신, 락 프리 큐를 사용하여, 락을 걸지 않고 큐의 읽고 쓰기를 하는 경우도 많다.

6. 파이프라인의 장단점

파이프라인 시스템은 한 번에 한 묶음씩 실행하는 시스템보다 더 많은 자원(회로 요소, 처리 장치, 컴퓨터 메모리 등)을 필요로 한다. 이는 파이프라인의 각 단계가 해당 자원을 공유할 수 없고, 요소 간에 버퍼링 및 추가 동기화 로직이 필요할 수 있기 때문이다.

개별 처리 요소 간의 항목 전송은 특히 긴 파이프라인의 경우 지연 시간을 증가시킬 수 있다.

파이프라인의 추가적인 복잡성 비용은 서로 다른 항목 처리 간에 의존성이 있는 경우, 특히 추측-백트래킹 전략을 사용하여 이를 처리하는 경우 상당할 수 있다. 실제로, 복잡한 명령어 집합에 대한 해당 전략 구현 비용은 컴퓨터 아키텍처를 단순화하려는 몇 가지 급진적인 제안, 예를 들어 RISC 및 VLIW를 촉진했다. 컴파일러 역시 명령어 파이프라인의 성능을 개선하기 위해 기계 명령어를 재배열하는 작업을 부담하게 되었다.

라인 생산 방식의 예에서 보인 것처럼, 파이프라인 처리는 단일 데이터의 처리를 고속화하는 것이 아니라, 데이터 스트림을 처리할 때 시스템의 처리율을 향상시킬 뿐이다.

파이프라인을 길게 하면, 지연 시간이 증가하여 하나의 신호가 파이프의 처음부터 끝까지 도달하는 데 시간이 더 걸리게 된다.

파이프라인화된 시스템에서는, 특정 스테이지가 이전 스테이지의 리소스(회로, 처리 장치, 메모리 등)를 재사용할 수 없기 때문에, 일반적으로 하나씩 처리하는 시스템보다 더 많은 리소스를 필요로 한다. 게다가, 파이프라인 처리에 의해 하나의 명령 완료에 걸리는 시간이 증가할 가능성이 있다.

7. 한국의 파이프라인 기술 현황 및 전망

최근 몇 년 동안 애플리케이션과 그 기반 하드웨어에 대한 요구 사항이 커졌다.[4] 예를 들어, 데이터를 행별로 훑어보는 단일 노드 애플리케이션으로 파이프라인을 구축하는 것은 빅 데이터의 양과 다양성으로 인해 더 이상 불가능하다.[4] 그러나 하둡과 같은 데이터 분석 엔진이나 최근의 아파치 스파크가 등장하면서, 대규모 데이터 세트를 여러 처리 노드에 분산하는 것이 가능해졌고, 애플리케이션이 이전에는 상상할 수 없었던 수백 배의 효율성에 도달할 수 있게 되었다.[4] 오늘날 이것의 효과는 분산 처리를 사용하여 이와 같은 방식으로 미들 레벨 PC조차도 빅 데이터 파이프라인의 구축 및 실행을 처리할 수 있다는 것이다.[4]

참조

[1] 웹사이트 Data Pipeline Development https://www.dativa.c[...] Dativa 2018-05-24
[2] 서적 Proceedings. Fifth International Symposium on Advanced Research in Asynchronous Circuits and Systems
[3] 웹사이트 MTDP https://github.com/d[...] 2022-09
[4] 웹사이트 What is a Data Pipeline? https://www.datapipe[...] Data Pipelines 2021-03-11
[5] 웹사이트 Graphics pipeline - Win32 apps | Microsoft Learn https://learn.micros[...]
[6] 뉴스 ゲームの中で「レイトレーシング」はどう使われる? 実例を見てみよう:レイトレーシングが変えるゲームグラフィックス(第2回)(1/3 ページ) - ITmedia PC USER https://www.itmedia.[...]
[7] 웹사이트 Data Pipeline Development https://www.dativa.c[...] Dativa 2018-05-24



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com